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The  objective  of  the  Engineer  Modeling  Study  is  to  measure  the  contri¬ 
bution  of  combat  engineers  to  the  effectiveness  of  the  combined  arms  team. 
The  research  program  originated  from  a  Mission  Area  Analysis  (the  Engineer 
Family  of  Systems  Study  (E-FOSS)),  which  noted  that  Army  war  games  were 
good  at  representing  unit  offensive  and  defensive  movements,  but  weak  in 
modeling  the  impact  of  US  and  Soviet  Union  combat  engineer  activities  on 
battle  outcomes.  In  1979,  the  US  Army  Engineer  School  (USAES),  represent¬ 
ing  the  Training  and  Doctrine  Command  (TRADOC) ,  requested  the  US  Army 
Construction  Engineering  Research  Laboratory  (CERL)  to  correct  this  defic¬ 
iency.  The  Engineer  Modeling  Study  was  the  result. 


The  Engineer  Modeling  Study  itself  is  part  of  the  larger  Army  Model 
Improvement  Program  (AMIP)  which  seeks  to  improve  the  caliber  and  quality 
of_ Axmy_vjaiLJ&aines The  three  AMIP  models  shown  in  Figure  1  interact  by 
feeding  scenarios  downward  from  higher  theater-level  games  to  lower  level 
division  and  battalion-level  games  and  by  transmitting  combat  results  up¬ 
ward  from  battalion-level  games  to  theater-level  models*  The  AMIP  model 
used  in  the  Engineer  Modeling  Study  is  the  mid-level  Corps/Division  Evalu¬ 
ation  Model  (CORDIVEM)  being  developed  by  the  Combined  Arms  Studies  and 
Analysis  Activity  (CASAA)o»  An  implicit  goal  of  the  Engineer  Modeling 
Utudyis  accurate  and  consistent  representation  of  the  effectiveness  of 
engineer  effort  throughout  the  AMIP  model  hierarchy.^ 

Figure  2  illustrates  how  the  Engineer  Modeling  Study  augments  the 
Corps/Division  Evaluation  Model  with  an  Engineer  Module.  This  module 
receives  orders  either  from  the  CORDIVEM  gamer  or  indirectly  from  within 
the  game;  the  module  then  modifies  various  CORDIVEM  terrain  features. 

These  terrain  modifications  produce  three  effects:  mobility  effects 
enhancing  the  movement  of  friendly  troops;  survivability  effects  reducing 
friendly  force  casualties;  and  countermobility  effects  delaying  the  move¬ 
ment  of  hostile  forces. 

The  Engineer  Module  is  comprised  of  the  three  submodules  (Figure  3): 
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an  interpret  order  submodule;  a  schedule  job  submodule;  and  a  perform 
activity  submodule*  Once  the  Engineer  Module  receives  orders  from  CORDIVEM, 
it  interprets  these  orders,  schedules  jobs  to  satisfy  these  orders,  per¬ 
forms  the  jobs,  and  appropriately  modifies  the  CORDIVEM  terrain. 

The  heart  of  the  perform  activity  submodule  is  a  set  of  critical  path 
networks.  For  example.  Figure  4  represents  the  precedence  network  for  a 
minefield  breach.  Each  step  of  this  technique  is  shown  as  an  activity. 
Given  the  location  of  the  job  site  and  the  locations  of  the  required 
resources,  the  perform  activity  submodule  determines  the  completion  time 
of  the  job  and  the  resources  expended. 

The  Engineer  Module  is  now  fully  operational.  It  is  compatible  with 
any  order  stream,  and  can  represent  over  50  separate  engineer  activities 
such  as  blowing  a  bridge,  building  a  command  post,  or  conducting  reconnais¬ 
sance  missions. 

The  schematic  diagram  shown  in  Figures  5,  6,  and  7  illustrate  the 
actual  operation  and  interaction  of  CORDIVEM  an id,  the  Eng ineer  Module. 
Everything  within  the  dashed  lines  belongs  to  CORDIVEM;  everything  outside 
the  dashed  lines  is  the  responsibility  of  the  Engineer  Module.  The  time 
clock,  or  event  queue,  for  CORDIVEM  appears  in  the  center;  CORDIVEM' s 
data  files  and  mapboard  appear  on  the  right.  The  operation  of  the  Engin¬ 
eer  Module  commences  on  the  left  with  the  receipt  of  an  order  from  COR¬ 
DIVEM,  generated  by  either  the  gamer,  a  pregame  plan,  or  the  CORDIVEM 
game  itself.  Regardless  of  the  source,  once  an  order  is  received,  it  is 
processed  by  the  interpret  order  and  schedule  job  submodules.  The  inter¬ 
pret  order  submodule  selects  an  appropriate  critical  path  network.  The 
schedule  job  submodule  then  places  the  start  times  for  the  individual 
events  of  the  critical  path  network  into  the  event  queue  of  CORDIVEM' s 
time  line.  The  Engineer  Module  then  goes  to  sleep  (Figure  5).  With  the 
passage  of  time,  CORDIVEM' s  TIME  NOW  marker  moves  downward.  When  TIME 
NOW  reaches  the  start  time  of  an  activity,  CORDIVEM  passes  control  of  the 
process  back  to  the  Engineer  Module's  perform  activity  submodule.  This 
submodule  computes  a  FINISH  TIME  and  places  a  marker  on  the  time  line 
in  the  appropriate  place  (Figure  6).  Finally,  when  TIME  NOW  reaches 
FINISH  TIME,  the  Engineer  Module's  modify  terrain  submodule  is  activated 
and  CORDIVEM1 s  data  base  is  changed  to  reflect  the  terrain  alteration. 

The  data  base,  in  turn,  changes  the  information  depicted  on  the  CORDIVEM 
map  (Figure  7). 

If,  at  some  subsequent  point  in  time,  enemy  and  friendly  forces 
engage  in  combat  in  that  location,  their  attrition  rates  and  movement  will 
be  modified  to  reflect  the  presence  of  the  engineer-created  terrain  fea¬ 
ture. 


figure  4 


EVENT  BASED  SIMULATION  (STEP  1) 
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EVENT  BASED  SIMULATION  (STEP  3 ) 
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Figures  8,  9,  and  10  are  computer-drawn  illustrations  which  depict 
how  the  CORDIVEM  model  ran  in  June  1981 ,  both  with  and  without  combat 
engineer  support.  Figure  8  represents  the  initial  situation  at  7  AM, 
where  five  outnunbered  blue  armored  cavalry  squadrons  (shown  in  white) 
confront  seven  red  tank  and  reconnaissance  battalions  (black).  By  after¬ 
noon,  without  engineer  support,  blue  forces  were  outflanked,  forced  to 
withdraw,  encircled,  and  finally  defeated  by  red  units  (Figure  9).  But 
utilizing  combat  engineer  support  on  the  battlefield,  bridges  were  destroy¬ 
ed  and  obstacles  placed  in  the  path  of  enemy  forces  to  impede  them  until 
adequate  defensive  fortifications  could  be  constructed  (Figure  10). 

These  efforts  enabled  blue  forces  to  withstand  the  enemy  attack  for  a  con¬ 
siderably  extended  period,  reduced  blue  losses,  and  increased  red  losses. 

The  results  of  these  conflicts  are  tabulated  in  Figure  11.  As  this 
table  indicates,  when  engineers  were  not  available,  red  lost  73  tanks 
while  blue  suffered  62  tank  casualties.  With  engineers  present,  red 
casualties  rose  to  88  tanks,  while  blue  casualties  fell  to  49  tanks.  It 
should  be  emphasized  that  these  results  were  derived  from  a  single  scenario 
and  many  additional  scenarios  must  be  executed  before  the  Engineer  Module 
is  credible. 

During  the  remainder  of  Fiscal  Year  82,  sensitivity  tests  on  the 
Engineer  Module  will  be  conducted  and  work  will  commence  on  a  way  to  model 
threat  engineers.  Engineer  Module  documentation  will  be  published  con¬ 
taining  flow  charts,  variable  listings,  definitions,  information  sources, 
and  an  operating  manual. 

In  the  more  distant  future,  the  Engineer  Module  will  be  used  to  con¬ 
duct  various  force  structure  trade-off  analyses  and  to  create  the  following 
stand-alone  Engineer  Modules:  A  Force  Structure  Trade-Off  Module  for  use 
in  force  design  analysis;  a  Combat  Engineer  Field  Module  for  use  by  combat 
engineer  units  for  operational  planning;  and  a  Combat  Engineer  Training 
Module  for  use  in  training  engineer  officers  and  others. 

To  suranarize.  The  Engineer  Module  is  merely  a  resource  allocation 
routine  which  receives  orders,  decrements  resources,  decrements  time, 
modifies  terrain,  and  Issues  statistics  (Figure  12).  The  Engineer  Module 
can  be  used  to  simulate  the  effects  of  different  command  and  control 
structures,  engineer  support  relationships,  and  engineer  equipment  perform¬ 
ance  characteristics.  This  ability  to  demonstrate  engineer  effectiveness 
on  the  battlefield  should  greatly  assist  efforts  to  modernize  and  field 
new  engineer  equipment. 
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Figure  12 


